1. Field of the Invention
The present invention relates to authentication technologies between a caller and a callee in a direct-routing mode in a communication system, particularly to a method and a system for distributing a session key across Gatekeeper (GK) zones in a direct-routing mode.
2. Background of the Invention
An H.323 system is implemented by a Packet Based Network (PBN) without guarantee on Quality of Service (QoS). Due to its own technical limitation, the PBN is unable to offer QoS or secure services. Therefore in the H.323 system, how to provide real-time and secure services is a problem to be solved.
Versions prior to H.235 protocol V.3 describe some technical solutions on authentication and encryption for the H.323 system, but all of the technical solutions are based on a GK-routing mode. ANNEX I of the H.235 V.3 provides a security solution based on the direct-routing mode, which mainly utilizes the basic features of ANNEX D and ANNEX F of the H.235 V.3 to offer secure service for the communication in the H.323 system, but the implementation of the solution is limited in one GK zone.
In a practical network scenario, an H.323 system usually includes two or more GKs. FIG. 1 is a block diagram illustrating a logical network structure of an H.323 system with two GKs.
As shown in FIG. 1, broken lines denote transmission paths of Registration, Admission and Status (RAS) messages described in the H.225 in the GK-routing mode; real lines denote transmission paths of Q.931 messages in the H.225 in the direct-routing mode. EndPoint a (EPa) and EPb are two H.323 EPs, GKg and GKh are two GKs. Wherein, the GKg is the GK of the calling EPa, and the GKh is the GK of the called EPb.
When the H.323 system includes two or more GKs, a pre-call appointment mechanism is usually employed to make the calling EPa and the GKg have a shared key Kag, the called EPb and the GKh have another shared key Kbh, and the GKg and the GKh have yet another shared key Kgh, so as to ensure the reliable transmission of the RAS messages.
If the calling EPa calls the called EPb in the direct-routing mode, reliable transmission of the RAS messages is required by both EPs to acquire a session key Kab, which guarantees the reliable direct transmission of the Q.931 messages in the H.225 between the calling EPa and the called EPb.
In the prior art, there are two methods for the calling EPa and the called EPb to carry out an authentication with the session key Kab when directly transmitting the Q.931 messages in the H.225.
Method 1: the GKh generates the session key Kab, the calling EPa and the called EPb carry out an authentication with the session key Kab generated by the GKh when transmitting the Q.931 messages in the H.225.
A detailed description of this method is given below:
As shown in FIG. 1, the calling EPa sends an Admission Request (ARQ) to the GKg, the request contains a ClearToken with a tokenOID filed set to “I0”, indicating that the calling EPa is capable of supporting the ANNEX I of the H.235 V.3, in other words, the calling EPa supports the RAS message transmission in GK-routing mode.
After receiving the ARQ message from the calling EPa, the GKg determines the information of the called EPb based on the value of a destinationInfo field or a destCallSignalAddress field in the ARQ message, and determines that the called EPb is not in the zone of the GKg based on the information of the called EPb. So the GKg sends a Location Request (LRQ) to the GKh, locating the called EPb. An endpointIdentifier field in the LRQ message can convey an Identifier (ID) of the calling EPa, indicating that it is the calling EPa that locate the called EPb.
When the GKg receives the ARQ message and finds out that the value of the tokenOID field of the ClearToken in the ARQ message is “I0”, it determines that the calling EPa is capable of supporting the ANNEX I of the H.235 V.3 and then generates a ClearToken with tokenOID set to “I0” in the LRQ message. If the GKg does not support the ANNEX I of the H.235 V.3, the GKg needs not to create the ClearToken with tokenOID set to “I0” in the LRQ message, and the subsequent information exchange process of the LRQ message is performed in a normal way as that when the ANNEX I of the H.235 V.3 is not supported, in other words, the messages will not be encrypted or decrypted at GKs during transmission.
After receiving the LRQ message, the GKh checks whether the value of the tokenOID of the ClearToken in the LRQ message is “I0”, if the value is “I0”, it indicates that the calling EPa is capable of supporting the ANNEX I of the H.235 V.3. If the GKh also supports the ANNEX I of H.235 V.3, the GKh inquire about that the called EPb is capable of supporting the ANNEX I of the H.235 V.3 and obtains the address of the called EPb based on the information of the called EPb in the LRQ message.
Then the GKh generates a random number “challenge” as well as a session key Kab for the transmission between the EPa and the EPb. The GKh generates an EKgh from a shared key Kgh between the GKh and the GKg and the random number “challenge” using a designated key derivation algorithm, and encrypts the session key Kab with the EKgh to generate an EKab1. Then the GKh sets the EKab1 and the parameters used in the encryption, such as the random number “challenge”, to a corresponding sub-field of an independent field ClearToken.h235Key.secureSharedSecret.
When there is an endpointIdentifier field in the LRQ message, the GKh also needs to set the EKab1 to a ClearToken.h235Key.secureSharedSecret.generalID field, and set the key derivation algorithm designated for the key generation to a ClearToken.h235Key.secureSharedSecret.keyDerivationOID field, set the random number “challenge” used for the key generation to a ClearToken.challenge field. At the same time, the GKh sets a ClearToken.generalID to be the ID of the GKg, and sets a ClearToken.senderID to be the ID of the GKh, and finally sets the value of tokenOID field in the ClearToken to be “I3”. The ClearToken will be hereinafter referred to as CTg.
The GKh generates the key EKbh from another random number “challenge” and the shared key Kgh between the GKh and the GKg using the designated key derivation algorithm, then encrypts the session key Kab with the EKbh to obtain an EKab2. After that the GKh sets EKab2 and parameters used in the encryption, such as the designated key derivation algorithm and the second random number “challenge”, to the h235Key.secureSharedSecret field of another ClearToken.
When there is an endpointIdentifier field in the LRQ message, the GKh also needs to set the EKab2 to the ClearToken.h235Key.secureSharedSecret.generalID field and set the second random number “challenge” used for the key generation to the ClearToken.challenge field. And the GKh also sets the ClearToken.generalID field to be the ID of the called EPb, sets the ClearToken.senderID field to be the ID of the GKh, and finally sets the value of tokenOID field in the ClearToken to “I2”. This ClearToken will be hereinafter referred to as CTb.
After the above configurations, the GKh sends a Location Confirm (LCF) message carrying the CTb and the CTg to the GKg.
After receiving the LCF message from the GKh, the GKg extracts the separate ClearToken information, i.e. the two ClearTokens, from the LCF message. The value of the tokenOID of one of the ClearTokens is “I3”, indicating that the ClearToken is the CTg; and the value of the tokenOID of the other ClearToken is “I2”, indicating that the ClearToken is the CTb. It is indicated that both the called EPb and the GKh are capable of supporting the ANNEX I of the H.235 V.3 and adopt the H.235 V.3 in security plan.
The GKg generates an Admission Confirm (ACF) message and creates a ClearToken in the ACF message. The value of the tokenOID of the ClearToken is set to “I1”. Then the GKg selects a third random number “challenge” and sets it to the CTa.challenge field, and obtains the parameters that the CTg used in the encryption, such as the random number “challenge” and the designated key derivation algorithm, so as to derive a key Ekgh from the shared key Kgh between the GKg and the called EPb using the key derivation algorithm designated by the random number “challenge”, then decrypt the Ekab1 in the CTg.h235Key.secureSharedSecret field of the LCF message with the key Ekgh, and thereby obtaining the session key Kab. The GKg then generates a key EKag with the third random number “challenge” in the CTa.challenge field and a shared key Kag between the calling EPa and the GKg using a designated key derivation algorithm. After that the GKg encrypts the session key Kab with the key EKag, and sets the encrypted data and the parameters used in the encryption, such as the third random number “challenge” and the designated encryption derivation algorithm, to corresponding sub-fields of the CTa.h235Key.secureSharedSecret. The encrypted result of encrypting the Kab with the Ekag and the parameters used in the encryption will be referred to as CTa hereinafter. Finally the GKg copies the CTb.generalID field into the CTa.h235Key.secureSharedSecret.generalID field, copies the CTb into the ACF message, and sends the ACF message carrying the CTb and the CTa to the calling EPa.
After receiving the ACF message, the calling EPa extracts the CTa and the CTb, and decrypts the encrypted data in the CTa with the key Ekag derived from the shared key Kag between the calling EPa and the GKg and through the designated encryption derivation algorithm and the third random number “challenge” in the CTa, so as to obtain the session key Kab.
After obtaining the session key Kab, the calling EPa establishes a Setup request with the session key and copies the CTb in the ACF message into the Setup request, then the calling EPa sets authentication information which is described in the ANNEX D of H.235 V.3 in the Setup request with the session key Kab and sends the Setup request via direct route to the called EPb.
After receiving the Setup request, the called EPb extracts the CTb and deduces the key EKbh based on the CTb.generalID, the CTb.sendersID and the CTb.challenge in the CTb and the shared key Kbh between the called EPb and the GKh. Then the called EPb decrypts the EKab2 in the CTb.h235Key.secureSharedSecret field of the CTb to obtain the session key Kab.
After obtaining the session key Kab, the called EPb authenticates the authentication information in the Setup request, if the authentication succeeds, process the Q.931 message transmission.
In the method described above, the inventor of the present invention found that the solution of method 1 may have the following disadvantages: the session key Kab between the calling EPa and the called EPb is encrypted and decrypted at the GK of every hop, therefore when there are a large number of GKs between the calling EPa and the called EPb, the time delay in the RAS message transmission will increase and since the session key Kab is exposed at the GK of every hop, the information security is poorly maintained.
Method 2: the GKg and the GKh perform a Diffie-Hellman (DH) key exchange to generate a session key Kab, which is used for authentication in the direct transmission of the Q.931 messages in the H.225 between the calling EPa and the called EPb.
A detailed description of this method is given below: As showed in FIG. 1, the calling EPa sends an ARQ message to the GKg, in which there is a separate ClearToken with a tokenOID set to “I0”. The calling EPa generates a public key for a DH negotiation and sets the public key to ClearToken.dhkey field before send the ARQ message.
The GKg, which is capable of supporting the ANNEX I of the H.235 V.3, receives the ARQ message and determines that the called EPb is not in the zone of the GKg based on the information of the called EPb in the ARQ message. Then the GKg sends an LRQ message to the GKh, in which there are a separate ClearToken with a tokenOID set to “I0” and a ClearToken.dhkey field which is identical with the ClearToken.dhkey field in the ARQ message, the ClearToken.dhkey field includes the DH public key generated by the calling EPa for the DH negotiation.
When there are other GKs between the GKg and the GKh, these intermediate GKs duplicate the LRQ message after receiving the LRQ message and send the duplicated LRQ message to an upper layer GK until the duplicated LRQ message reaches the GKh.
After receiving the LRQ message, the GKh determines that both the calling EPa and the called EPb support the ANNEX I of the H.235 V.3 based on the ClearToken.tokenOID field and the information of the called EPb in the LRQ message. Then the GKh creates a ClearToken with a tokenOID set to “I2”. The ClearToken is referred to as CTb hereinafter.
The GKh generates a private key for the DH negotiation, and further calculates out a session key Kab from the public key just generated and the public key in the received LRQ message using the DH algorithm for the direct transmission of Q.931 messages between the calling EPa and the called EPb.
The GKh then generates a random number “challenge” and sets it to the CTb.challenge field. After that the GKh deduces a key EKbh and a key KSbh through the designated key derivation algorithm on the basis of the random number “challenge” and the shared key Kbh between the called EPb and the GKh. The GKh generates a random initialization vector IV and sets it to the CTb.h235Key.securitySharedSecret.paramS.IV field. The GKh encrypts the session key Kab with the key EKbh, the key KSbh and the initialization vector IV to obtain an ENCEKbh, KSbh, IV(Kab), and sets the ENCEKbh, KSbh, IV(Kab) to the CTb.h235Key.securitySharedSecret.encryptedSessionKey field. Such method for encrypting the session key Kab is described in the ANNEX I of H.235 V.3.
The GKh sends an LCF message including the private key and the CTb generated by the GKh to the GKg.
The GKg receives the LCF message from the GKh, obtains the CTb and the private key generated by the GKh, copies the CTb and the private key into an ACF message, and sends the ACF message to the calling EPa.
After receiving the ACF message, the calling EPa deduces the session key Kab from the private key generated by the GKh in the ACF message and the public key of the calling EPa using the DH algorithm.
After obtaining the session key Kab, the calling EPa creates a Setup request according to the session key Kab and copies the CTb in the ACF message into the Setup request, then the calling EPa configures authentication information which is described in the ANNEX D of the H.235 V.3 in the Setup request according to the session key Kab, and sends the Setup request to the called EPb.
The called EPb receives the Setup request and extracts the CTb. Based on the information in the CTb, which are the random number “challenge”, the designated key derivation algorithm and the shared key Kbh between the called EPb and the GKh, The called EPb deduces the key EKbh and the key KSbh, then decrypts the ENCEKbh, KSbh, IV(Kab) in the CTb.h235Key.secureSharedSecret.encryptedSessionKey field with the EKbh, the KSbh and the initialization vector IV in the CTb to obtain the session key Kab. Finally the EPb authenticates the Setup request with the session key Kab.
Although the second method described above overcomes the time delay in the RAS message transmission and the security problem generated by the exposure of session key Kab at GK of every hop, the inventor of the present invention found that the solution of the method 2 may have the following disadvantages: the method requires that the calling EPa and all the GKs between the calling EPa and the called EPb support the DH negotiation, which limits its application.
Although this method has solved the problem of the increased RAS message transmission delay, and the poor security performance of the session key Kab incurred by being exposed when passing through the GK of each hop. However, the method needs both the calling EPa and the GKs between the calling EPa and the called EPb to support the DH negotiation process, which limits the application of the method.
In summary, the caller's GK and the callee's GK can not select the method for distributing the session key for the calling and the callees, which makes the session key distributing methods lack of flexibility.